'\" te
.\"  Copyright (c) 1999, Sun Microsystems, Inc.  All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH DDI_DEV_REPORT_FAULT 9F "Aug 13, 1999"
.SH NAME
ddi_dev_report_fault \- Report a hardware failure
.SH SYNOPSIS
.nf
#include <sys/ddi.h>
#include <sys/sunddi.h>



\fBvoid\fR  \fBddi_dev_report_fault\fR (\fBdev_info_t   *\fR\fIdip\fR,
     \fBddi_fault_impact_t\fR \fIimpact\fR, \fB ddi_fault_location_t\fR \fIlocation\fR,
     \fBconst char   *\fR\fImessage \fR);
.fi

.SH INTERFACE LEVEL
illumos DDI specific (illumos DDI)
.SH PARAMETERS
.ne 2
.na
\fB\fIdip\fR \fR
.ad
.RS 13n
Pointer to the driver's \fBdev_info\fR structure to which the fault report
relates. (Normally the caller's own \fBdev_info\fR pointer).
.RE

.sp
.ne 2
.na
\fB\fIimpact\fR \fR
.ad
.RS 13n
One of a set of enumerated values indicating the impact of the fault on the
device's ability to provide normal service.
.RE

.sp
.ne 2
.na
\fB\fIlocation\fR \fR
.ad
.RS 13n
One of a set of enumerated values indicating the location of the fault,
relative to the hardware controlled by the driver specified by \fBdip\fR.
.RE

.sp
.ne 2
.na
\fB\fImessage\fR \fR
.ad
.RS 13n
Text of the message describing the fault being reported.
.RE

.SH DESCRIPTION
This function provides a standardized mechanism through which device drivers
can report hardware faults.  Use of this reporting mechanism enables systems
equipped with a fault management system to respond to faults discovered by a
driver. On a suitably equipped system, this might include automatic failover to
an alternative device and/or scheduling replacement of the faulty hardware.
.sp
.LP
The driver must indicate the impact of the fault being reported on its ability
to provide service by passing one of the following values for the impact
parameter:
.sp
.ne 2
.na
\fB\fBDDI_SERVICE_LOST\fR\fR
.ad
.RS 26n
Indicates a total loss of service. The driver is unable to implement the normal
functions of its hardware.
.RE

.sp
.ne 2
.na
\fB\fBDDI_SERVICE_DEGRADED\fR\fR
.ad
.RS 26n
The driver is unable to provide normal service, but can provide a partial or
degraded level of service. The driver may have to make repeated attempts to
perform an operation before it succeeds, or it may be running at less than its
configured speed. A driver may use this value to indicate that an alternative
device should be used if available, but that it can continue operation if no
alternative exists.
.RE

.sp
.ne 2
.na
\fB\fBDDI_SERVICE_UNAFFECTED\fR\fR
.ad
.RS 26n
The service provided by the device is currently unaffected by the reported
fault. This value may be used to report recovered errors for predictive failure
analysis.
.RE

.sp
.ne 2
.na
\fB\fBDDI_SERVICE_RESTORED\fR\fR
.ad
.RS 26n
The driver has resumed normal service, following a previous report that service
was lost or degraded.  This message implies that any previously reported fault
condition no longer exists.
.RE

.sp
.LP
The location parameter should be one of the following values:
.sp
.ne 2
.na
\fB\fBDDI_DATAPATH_FAULT\fR\fR
.ad
.RS 22n
The fault lies in the datapath between the driver and the device. The device
may be unplugged, or a problem may exist in the bus on which the device
resides.  This value is appropriate if the device is not responding to
accesses, (for example, the device may not be present) or if a call to
\fBddi_check_acc_handle\fR(9F) returns \fBDDI_FAILURE\fR.
.RE

.sp
.ne 2
.na
\fB\fBDDI_DEVICE_FAULT\fR\fR
.ad
.RS 22n
The fault lies in the device controlled by the driver. This value is
appropriate if the device returns an error from a selftest function, or if the
driver is able to determine that device is present and accessible, but is not
functioning correctly.
.RE

.sp
.ne 2
.na
\fB\fBDDI_EXTERNAL_FAULT\fR\fR
.ad
.RS 22n
The fault is external to the device.  For example, an Ethernet driver would use
this value when reporting a cable fault.
.sp
If a device returns detectably bad data during normal operation (an
"impossible" value in a register or DMA status area, for example), the driver
should check the associated handle using \fBddi_check_acc_handle\fR(9F) or
\fBddi_check_dma_handle\fR(9F) before reporting the fault. If the fault is
associated with the handle, the driver should specify  \fBDDI_DATAPATH_FAULT\fR
rather than \fBDDI_DEVICE_FAULT\fR. As a consequence of this call, the device's
state may be updated to reflect the level of service currently available. See
\fBddi_get_devstate\fR(9F).
.sp
Note that if a driver calls \fBddi_get_devstate\fR(9F) and discovers that its
device is down, a fault should not be reported- the device is down as the
result of a fault that has already been reported. Additionally, a driver should
avoid incurring or reporting additional faults when the device is already known
to be unusable. The  \fBddi_dev_report_fault()\fR call should only be used to
report hardware (device) problems and should not be used to report purely
software problems such as memory (or other resource) exhaustion.
.RE

.SH EXAMPLES
An Ethernet driver receives an error interrupt from its device if various fault
conditions occur.  The driver must read an error status register to determine
the nature of the fault, and report it appropriately:
.sp
.in +2
.nf
static int
xx_error_intr(xx_soft_state *ssp)
{
    ...
    error_status = ddi_get32(ssp->handle, &ssp->regs->xx_err_status);
    if (ddi_check_acc_handle(ssp->handle) != DDI_SUCCESS) {
        ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST,
            DDI_DATAPATH_FAULT, "register access fault");
        return DDI_INTR_UNCLAIMED;
    }
    if (ssp->error_status & XX_CABLE_FAULT) {
        ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST,
            DDI_EXTERNAL_FAULT, "cable fault")
        return DDI_INTR_CLAIMED;
    }
    if (ssp->error_status & XX_JABBER) {
        ddi_dev_report_fault(ssp->dip, DDI_SERVICE_DEGRADED,
            DDI_EXTERNAL_FAULT, "jabbering detected")
        return DDI_INTR_CLAIMED;
    }
    ...
}
.fi
.in -2

.SH CONTEXT
The \fBddi_dev_report_fault()\fR function may be called from user, kernel, or
interrupt context.
.SH SEE ALSO
.BR ddi_check_acc_handle (9F),
.BR ddi_check_dma_handle (9F),
.BR ddi_get_devstate (9F)
